Changing the release method?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Changing the release method?

Natale Patriciello

Hi all,

as I've seen during these years, every release is more a pain than a
relief, especially for Tom that has to track everything (I know he is tracking
everything even when we aren't close to a release, but the pressure is higher
when the deadline comes).

Why we don't release, every 3 months, a rolling snapshot of our
current repo? What is inside, is inside, and what is not, is not. To
signal the change, the numbering would change to the date (or the
year/month as Ubuntu does).

Yes, ns-3.20.06 seems a nice name to me :)

Ciao,

Nat
Reply | Threaded
Open this post in threaded view
|

Re: Changing the release method?

Tom Henderson-2
On 6/2/20 12:51 PM, Natale Patriciello wrote:

> Hi all,
>
> as I've seen during these years, every release is more a pain than a
> relief, especially for Tom that has to track everything (I know he is tracking
> everything even when we aren't close to a release, but the pressure is higher
> when the deadline comes).
>
> Why we don't release, every 3 months, a rolling snapshot of our
> current repo? What is inside, is inside, and what is not, is not. To
> signal the change, the numbering would change to the date (or the
> year/month as Ubuntu does).
>
> Yes, ns-3.20.06 seems a nice name to me :)

I agree that feature-driven releases are not working, and would like to
change to something like the above, perhaps for the next release (I
would prefer to avoid adding a new naming scheme to what is already
pending).

- Tom

Reply | Threaded
Open this post in threaded view
|

Re: Changing the release method?

Tommaso Pecorella
I agree, and I'll raise a bit the bar. I was indeed about to send a mail on this point but I got carried away.

Here's the original mail. The topic was "a modest proposal"
----------------------------------------
... let's eat Ireland's babies (see also https://www.gutenberg.org/files/1080/1080-h/1080-h.htm <https://www.gutenberg.org/files/1080/1080-h/1080-h.htm>).

No, seriously. We should regenerate the bindings as part of the commit process, and not just for the module we're modifying, also for its dependencies.
This takes a lot of time but bisecting takes more time.

Things to so:
1) A clear, up-to-date instruction page on how to rebuild the bindings on a recent machine.
2) Remove all the old wikis on the same topic, and make sure that the manual isn't misleading.
3) Reject any merge request not containing the bindings for the modules affected by the changes.

Point 3 might means "all" in the case of some modules (e.g, network, core, etc.).

T.
----------------------------------------

Along with this (Tom shouldn't the one responsible for regenerate the bindings), I fully second the idea to get back on a time-based release schedule.
Plus, I'd like to go back to the good habit of:
- 2 months for adding features
- 1 month to fix bugs, divided in:
  - 3 weeks of general bugfixing
  - 1 week to fix only the critical bugs.
-> release

It should be a responsibility of whoever proposes a merge to time their proposals, and to push them when the time is right.


Cheers,

T.


> On 2 Jun 2020, at 23:40, Tom Henderson <[hidden email]> wrote:
>
> On 6/2/20 12:51 PM, Natale Patriciello wrote:
>> Hi all,
>>
>> as I've seen during these years, every release is more a pain than a
>> relief, especially for Tom that has to track everything (I know he is tracking
>> everything even when we aren't close to a release, but the pressure is higher
>> when the deadline comes).
>>
>> Why we don't release, every 3 months, a rolling snapshot of our
>> current repo? What is inside, is inside, and what is not, is not. To
>> signal the change, the numbering would change to the date (or the
>> year/month as Ubuntu does).
>>
>> Yes, ns-3.20.06 seems a nice name to me :)
>
> I agree that feature-driven releases are not working, and would like to change to something like the above, perhaps for the next release (I would prefer to avoid adding a new naming scheme to what is already pending).
>
> - Tom
>

--------------------------------------------------------------

``Stealing from one is plagiarism,
  stealing from many is research.''
-- Wilson Mizner

--------------------------------------------------------------

Tommaso Pecorella - Ph.D.

Assistant professor
Dpt. Ingegneria dell'Informazione
Università di Firenze

CNIT - Università di Firenze Unit

via di S. Marta 3
50139, Firenze
ITALY

email: [hidden email]
       [hidden email]

phone : +39-055-2758540
mobile: +39-320-4379803
fax   : +39-055-2758570