[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: breeze-icons_5.36.0-1_amd64.changes is NEW



In data giovedì 13 luglio 2017 21:16:21 CEST, Maximiliano Curia ha scritto:
> ¡Hola Pino!
> 
> El 2017-07-13 a las 07:24 +0200, Pino Toscano escribió:
> >> 9179b08feae424df136fff92f15d8ddc54c69423 is the latest change in git made by 
> >> you and 5.36.0-1 is based on that, I haven't noticed that there was a 5.28.0-2 
> >> uploaded that is not in the git.
> 
> > Yes, and that's exactly one of the issues, and not the first time this 
> > issue happens. Since these packages are (still) team-maintained, 
> > uploading things without checking
> 
> > a) what is done in git
> 
> Please, next time upload your changes and that makes an easier
> workflow.

When uploading something, I push the "upload to $SUITE" commits, and
the tag of that upload only *after* I get the "ACCEPTED" email for that
upload. Since it was stuck in NEW, then that stuff stays in my local
clone until the upload gets out of NEW. This is not an arbitrary whim,
but I do that because the upload could be rejected for whatever
reasons, and thus that commit & the tag would be totally invalid.

Oh, and btw, I push those commits ASAP, unlike stuff (like tags)
uploaded by you which remain unpushed even for months.

> The new version was prepared with what was on git.

As written above, the stuff was not pushed for valid reasons.
OTOH, you didn't even noticed the version in NEW, and pushed your stuff
directly to master, even!

> > b) what was already uploaded, and/or stuck in some queue somewhere
> > is not really acceptable. Please be respectful of other people's work.
> 
> It's not lack of respect, I missed the uploaded message,

As already happened various times in the past, pointed to you, and
being told "sorry, I will check next time".

> we will have to merge the changes, nothing is lost

Sure, but things are made more complicated and messy for no reason.

> no need to make an issue about it.

Considering this is a recurring behaviour, it is not me who is causing
this issue.

> Happy hacking,

It would be nice indeed, if somebody would not make other people's work
wya more harder than it should be, by handling "team repositories" as
his own, not even checking what was done by other people, and *why*.

There are reasons why I try to avoid as much as possible to work on
things where you work as well, and at this point should be clear
enough what are they.

-- 
Pino Toscano

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: